Packet carrier networks are composed of bridges or switches that are interconnected to each other using NNIs (Network to Network Interfaces). The bridges at the edges of the network are called “edge bridges”, while all interior bridges are called “core bridges”. Customers are connected to the edge bridges (either directly or through a CPE (customer premises equipment)) through a UNI (User to Network Interface).
One example of such a network 10 is illustrated schematically in FIG. 1. Network 10 includes a plurality of core bridges 12 coupled to one another via NNIs 14, a plurality of edge bridges 16, each coupled to one core bridge 12 also via an NNI 14, and a plurality of CPE bridges 18, each coupled to one edge bridge 16 via a UNI 19. The edge, core and CPE bridges have similar structures but different functionalities.
Ethernet is a connectionless oriented packet forwarding technology. It does not have a routing mechanism and its address scheme is based on 48-bit media access control (MAC) addresses. Since this address scheme is not scaleable, in order to provide greater capacity, a partitioning scheme, named VLAN, was introduced.
A VLAN, or virtual LAN, is a logical group of LAN segments, independent of physical location, with a common set of requirements. Several VLANs can co-exist on a single physical bridge. VLANs are configured through software rather than hardware, which makes them extremely flexible. Frames having a VLAN tag carry an explicit identification of the VLAN to which they belong, as well as identifying the specific customer and service. The value of the VLAN Identification (VID) in the tag header of the frame signifies the particular VLAN the frame belongs to. This additional tag field appears in the Ethernet protocol.
As the carrier network may use different bridging standards than the customer (CPE) bridging (for example, because carrier Ethernet bridging must support large scale bridging), the edge bridges are required to translate the frames entering and exiting the carrier network from and to the bridging protocol of the customer equipment. An example is the insertion of a tag at the ingress (UNI) port of the carrier edge bridge and the stripping of the tag at the egress (UNI) port. In an Ethernet network, the tag can be a VLAN tag while, in other networks, other tagging packet methods can be utilized, such as MPLS, VPLS, T-MPLS, etc.
Ethernet VLAN frames are relayed through a series of Ethernet bridges in the network. Each bridge has a VLAN filtering database, which contains rules for forwarding a received data frame. The forwarding is carried out based on the data frame's destination MAC address and associated VID. The filtering database contains both management configured statistical information and dynamically learnt information during bridge operations. In the filtering database, information related to MAC addresses is known as filtering information and the information related to VLANs is known as registration information. Among the decisions made according to the rules in the database, one is whether the frame is to be unicast (forwarded through a single port of the bridge) or multicast (forwarded simultaneously through several ports).
The main problem with VLAN is its limited VID space (4096 unique VIDs in a networking environment). While this space may suffice for enterprise applications, it is much too small for carrier networks, which must support many customers and services. Another problem with VLAN is that, while it limits the number of MAC addresses learned per customer in specific VLAN associated ports, still within this VLAN, all the MAC addresses of all the customers' end stations associated with the port must be learned and stored by each bridge. This is assuming that VLAN to VLAN communication between customers' end stations exists, and thus, their internal VLANs can communicate as well.
A number of solutions have been proposed for the scalability problem. The first is the so called Q-in-Q solution, also known as Provider Bridge. It entails VLAN stacking or tag stacking, which allows service providers to insert an additional VLAN tag (referred to as provider VLAN) in the Ethernet frame in order to identify the service, thus resulting in a unique 24-bit length label. Even in this system, one provider VLAN is dedicated to one customer (C-VLAN), and therefore the number of supported customers per Service VLAN (S-VLAN) is still limited to 4094. Q-in-Q, therefore, does not solve the problem of the quantity of addresses to be learned, since all the MAC addresses of all the customers' end stations associated with the ports of the specific S-VLAN must be learned and stored.
TLS (Transparent LAN Services) are carrier services provided by carriers to customers, which enable customers to have LAN (local area network) connectivity over a carrier WAN/MAN (Wide area network/Metro area network). TLS means that customers have a service that resembles a private LAN (or VPN “virtual private network”). A logical representation of an example of a TLS scheme 20 on the network of FIG. 1 is shown schematically in FIG. 2. In this example, CPEs 18, 18′ and 18″ are coupled to one another by TLS 20 and can communicate with one another through the intermediary core and edge bridges, which are transparent to the CPEs. As shown in FIG. 3, in order to provide such a service, the carrier may assign a unique identifier per customer, e.g., a VLAN 22, which distinguishes this specific customer's service instance within the carrier's network from others, for routing packets within the TLS. If the TLS were only point to point between two CPEs, there would be no need for any of the edge devices to learn the clients' MAC addresses of any of the CPEs, since all packets would be routed via VLAN 22. However, as can be seen in the example in FIG. 3, TLS 20 has an intersection or split point 24, where incoming packets have a choice of two egress directions. Since VLAN 22 cannot distinguish between these two CPEs, the edge bridges have no choice but to learn the client MAC addresses of all the CPEs, in order to provide the proper routing.
Thus, there are a number of problems with providing one VLAN for each TLS: 1. The limited numbers of VLANs available; 2. All edge bridges must store all MAC addresses of all customers at each edge bridge, in order to enable per customer bridging; and 3. At each VLAN splitting point (egress at two or more links) within the core, the core bridges also need to store all possible customers' MAC addresses in order to enable forwarding. All networks that provide TLS suffer from these problems, not only Ethernet.
Another TLS implementation is to use full mesh connectivity, such as in VPLS or HVLAN, illustrated schematically in FIG. 4. In this implementation, the service 30 is partitioned into all the point to point connections possible between all CPEs out to the edge bridges, and the TLS is implemented over a mesh of unicast, point to point links 32. Each CPE is connected only to its associated edge bridge. Optionally, a separate multicast link 34 can be also added to enable better multicast support. (Since a multicast link (multicast tree) always sends frames to all destinations, regardless of MAC address, there is no need to store customer MAC addresses in the core switches for multicast purposes.)
While this method solves two problems, namely the limited number of VLANs (alleviated by tunneling) and the splitting point at the core (by transforming the service to a set of unicast connections), it still has the drawback of requiring all the edge bridges to store all MAC address of all clients.
An alternative solution proposed for the problem of scalability is known as MAC-in-MAC or PBB (Provider Backbone Bridges), described in the proposed IEEE 802.1ah Provider Backbone Bridges standard. The MAC-in-MAC name refers to the way in which the standard encapsulates Ethernet frames with a Service Provider MAC header. MAC-in-MAC technology overcomes the inherent scalability limitations of VLANs and Q-in-Q networks that make them impractical for use in larger networks by enabling up to 4000 times as many service instances as are supported by traditional VLAN and Q-in-Q networks. Because the switches at the edge encapsulate the traffic with a service provider MAC address, the other switches in the core need only learn the MAC addresses of the core switches.
The problem with PBB arises from the requirements of the edge bridges to provide a bridging instance per customer (as the customer frames are encapsulated with a backbone MAC address) in order to enable TLS. Providing this bridging instance service requires all edge bridges that participate in a specific TLS instance to learn all customers' MACs from all points associated with this service. This leads to huge forwarding tables in the edge devices.
IP networks can also be divided into smaller networks, called subnetworks or subnets. An IP subnet address is created by “borrowing” bits from the host field and designating them as the subnet field. The number of borrowed bits varies and is specified by a subnet mask, which is stored in the router's routing tables. Subnet masks use the same format and representation technique as IP addresses. During IP routing, these subnet masks are used to determine the network (or more specifically, the subnetwork) address.
Subnet masks have recently been proposed by the present applicants' pending application for use in Ethernet networks, in PCT published application WO2008/029415. This application proposes a configurable Ethernet bridge having a filtering database including a plurality of subnet masks for receiving and forwarding frames according to a hierarchical address scheme.
A major problem with subnet masks, as used today, is that the actual addresses are pruned, i.e., only a certain portion is used for routing in the routing tables. And, during pruning, the portion which is not utilized becomes inaccessible for operation, administration and maintenance (OAM). Thus, in case of error in routing or a problem in the network, there is no possibility of retrieving the original address, once a subnet mask has been applied.
A similar problem arises when using conventional tunneling methods of forwarding. Conventional methods (like Q-Q, M-M, HVLAN, etc) reduce the number of forwarding states (i.e., entries in forwarding tables) at the core devices by aggregating many customer service instances (e.g., C-VLANS) into a smaller number of service provider's service instances (e.g., S-VLANs). This is accomplished by forwarding only according to the S-VLAN table. The problem is that, if an OAM operation is needed (for example, to discover why a customer specific service is malfunctioning), it is not possible to check this at the core bridges at a customer level as the core device is only aware of the service tunnels' levels, as a result of the pruning.
Accordingly, there is a long felt need for a packet carrier network which can provide Transparent LAN Services without requiring very large routing tables for MAC addresses, and it would be desirable to use tunneling in such a way that the original service instance remains retrievable in case of need.